After the replicator is stopped, it may still take some time to wind down objects Our test currently allows 2 seconds for it. This turns out not enough in situation when there are following errors,

Sync ERROR Obj=/Repl#21/revfinder#26/ Got LiteCore error: LiteCore NotOpen, "database not open"

This error is artificial. It is because we close the database as soon as the replicator goes to stopped, as opposed to when the replicator is deleted. The error follows the exception to the top frame and takes substantial time when there are many of them.

I increased 2 seconds allowance to 20 seconds. We won't always wait for 20 seconds, because the waiter polls the condition every 50ms. A situation of actual memory leak will wait for whole 20 seconds before failure.

…2112)

The reason the test occasionally fails because we assumeed that successive revisions all get replicated to the destinations, whereas replicator may skip obsolete revision, say rev-2, when rev-3 exists when the pusher turns to find the revisions to push. In our test case, we create successive revisions in intervals of 500 milliseconds. Most time, 500 ms is enough to set apart when the pusher picks the revisions. On Jenkins machine, the log shows that it found obsolete revisions when the test failed.

We modified the test success criteria: we only check that the latest revisions are replicated to the destination. This is the designed behavior.

Allow several timeouts to the HTTP Request. For now, allowing 4 timeouts with each timeout being 5 seconds.

Added a flag to C4DatabaseFlags, kC4DB_DiskSyncFull. This flag is passed to DataFile::Options, which is used as we request a connection to the SQLite database.

* Fixed crash when converting from address (Address) to C4Address by using the cast operator instead of casting the pointer which is not valid anymore due to the change in private variables.

* When creating an address object, used the path not full url for the path.

…2_master